Every year, embedded hardware and software developers face new challenges. Some of these come from industry trends, such as the increasing use of machine learning at the edge. Others are driven by customer and market expectations, such as delivering more functionality in a smaller enclosure with a lower BOM cost. And let’s remember the need for sustainability in design and the increasing legislation covering batteries and battery waste. For developers, keeping up to date with trends takes time, but putting it into practice takes even longer.
As machine-learning algorithms progress toward the edge and demand for functionality increases, embedded systems become more complex. This fact is highlighted in a 2022 article by management consultancy firm McKinsey titled “Cracking the complexity code in embedded systems development.” The article listed many contributing factors, including marketability over engineerability, a topic most engineers know only too well. However, all of the above factors are set against an embedded development process that has remained largely unchanged for decades. Today’s integrated development environments have advanced considerably in the past two decades but still function based on the code, compile and debug cycle.
Nevertheless, the ecosystem of hardware and software tools available to developers is expanding, easing development challenges and opening up opportunities for development teams to increase device functionality. EE Times Europe has investigated three products that may reduce the burden on engineering.
Embedding insight into your application
During this year’s Embedded World conference, software company Qt (Helsinki) launched Qt Insight, an insight and analysis application for embedded systems that the company describes as providing real customer insights into the usage of applications and embedded devices. EE Times Europe spoke with Petteri Holländer, senior vice president of Qt Ventures, to find out more about Qt Insight and its suitability for embedded designs.
Qt Ventures’ Petteri Holländer.
Qt Ventures’ Petteri Holländer
“In the past, most embedded devices didn’t have any network connection, so the only feedback on user experience that manufacturers could gain was from a focus group, and that was after the fact, when the product was in the market,” Holländer said. “Now, with more connected embedded devices, customers have asked us about collecting user feedback, updating device firmware and even displaying ads on screens. Something we found by running pilot cases with customers—and it’s sort of obvious—is that what the device manufacturer thinks the user workflow will be is not how users are actually using it.
“Imagine a coffee machine used in a chain of coffee outlets,” he said. “How do you know how often they are used and when? Is it busier in the morning or the afternoon? What type of coffee and roast is more popular than others? The coffee machine is a simple example, but you could apply it to, for example, an automotive infotainment system. Now that we’re so connected, it’s about making users happy, updating the user interface and potentially displaying advertising for some applications.”
Holländer cited the ability to “promote the correct usage of a device by monitoring the workflow users took to a particular function and suggesting tips to a user that there is an easier way to get to that function. You can do this interactively and dynamically by advising the user or changing the user experience going forward.”
One reason Qt Insight might be used, Holländer said, is to find out “what part of an application or device is not actually used at all. Manufacturers have their ideas on how people might use the device, but there’s a sort of 80/20 rule. Eighty percent of the usage is done by 20% of the functionality, but there’s most probably also 20% of the device that will never be used at all. So you could be developing and maintaining features and functionality that nobody ever uses. That’s very valuable insight, allowing you to remove excess functionality, and it might even bring a longer lifetime to a device.”
Sustainability and energy profiling
The embedded industry is well-versed in the benefits of low-power design. The popularity of the internet of things gave low-power design a huge push, even though the concepts are decades old. What constitutes a low-power design varies tremendously, but anything battery-powered is a candidate. Imagining how to implement a low-power regime is relatively straightforward, but putting it into practice requires accurate and timely energy measurement.
Qoitech (Lund, Sweden) launched its Otii Arc power profiler and energy analyzer unit in 2018 and has recently added a new model, the Otii Ace Pro. The Ace Pro accommodates operating voltages up to 25 VDC, a maximum current of 5 A and a resolution of 0.4 nA, without any burden voltage imposed on the device under test. Recent additions to the measurement software options include Otii Battery and Otii Battery Analytics & Validation toolboxes.
EE Times Europe asked Qoitech CEO Vanja Samuelsson whether developers are leaving energy consumption profiling to the last minute. “Compared with three years ago, it’s better, but I think we are still far from what some of our customers are doing today,” she said. “Some are really thinking through the whole development phase, the whole stack in a sense, with a low-power mindset. Many customers are involved in metering, monitoring and tracking [devices], and they have realized that you can’t change the battery too often.”
Samuelsson referred to companies selling the whole package, meaning an expensive device and monitoring application: “You can’t go back in two weeks and say, ‘Hey, we need to change all these batteries.’ Consequently, they have in their mind that they need to deliver a guaranteed battery life, which is scary. We are seeing more and more customers making energy profiling and prolonging battery life a big deal. This is because they are tired of the firefighting at the end of the project. If you don’t optimize the design, it will bite you later, especially since all the projects are multidisciplinary.”
When asked what advice she would give embedded developers, Samuelsson said, “The No. 1 things are trying to have a bit more of a bird’s-eye view of the project and to keep measuring. The second would be to understand what possible changes could happen during the project and after it is launched. If you have brought the most beautiful low-power product to market and you push out an over-the-air software update that doesn’t take care of everything you did in the previous profile, it will ruin everything. Make sure you measure the update’s power before it goes live, and get everyone else on the team to measure it and give feedback. I think this also makes the development more of a team play.”
Leveraging machine learning for embedded development
The embedded industry is awash with use cases for incorporating machine-learning algorithms into IoT devices. However, startup company Embedd.it (London) is working on improving developer productivity by using machine learning to write device drivers.
Embedd.it CEO Michael Lazarenko told EE Times Europe how the company started: “As an embedded developer, what created friction was the language of communication between a semiconductor manufacturer and an embedded developer being a PDF document. We saw an opportunity to use machine learning to structure and understand the data in the PDF and then use some proven code-generation technologies to put things together for the developer. This will help them abstract from the hardware, which would also help them port to another semiconductor firmware.”
When asked whether developers may be concerned that they no longer have visibility of the low-level functions, Lazarenko said, “We give full transparency of the data that’s going into the driver, and we also provide them full access to the source code. From what we are seeing, there is still at least 20% of the development time to be allocated to driver development, but we can speed up that process by 80%.
“Also, we don’t just generate the driver code; we create test suites the developer can use,” Lazarenko added. “It’s a C application that emulates the component’s behavior, and you can run it on physical hardware. So that means that not only do we generate the driver, but you can also significantly speed up debugging since you have test code already written.” Lazarenko gave an example of a Wi-Fi module he had previously worked on that had a mistake on the datasheet, taking him a month to debug the driver. “We want to address this [challenge],” he said. “It’s about making the whole process of hardware-to-software connection seamless.”